SCA Service Component Architecture provides an open, technology-neutral model for implementing IT services that define a business function. The SCA also provides a model for the assembly of business solutions from collections of individual services, with control over aspects of the solution such as access methods and security. With a SCA, customers are able to more easily create new, and transform existing, IT assets into reusable services that may be rapidly adapted to changing business requirements. The specifications that enable the building of SCA (middleware) components take advantage of a Service-Oriented Architecture (SOA), which structures IT assets as a series of reusable services that perform business functions. The Service Oriented Architecture combines the ability to invoke remote objects and functions (called “services”) with tools for dynamic service discovery, placing an emphasis on interoperability. Currently, a goal of the industry is to provide application developers with simpler and more powerful ways of constructing applications based on SOA.
Moreover, in the development of distributed systems implementing SCA components, it is a goal to provide for transparent and fault-tolerant availability of ‘non-volatile’ data that may either represent persistent ‘settings’ (to be stored on mass-media throughout the distributed system) or ‘state’ preserved in a fault-tolerant manner. Presently, the development of distributed fault-tolerant and highly available systems is ad-hoc, error-prone, and time-consuming. Current solutions are analogous to an example currency exchange system where the fluctuation of currency price and exchange operations may be out of order or non-atomic. Execution is usually non-deterministic due to the network or threading: Existing mechanisms for persistence (entity beans, JDBC, etc) are heavyweight, and they necessitate extra knowledge and extra code.
For example, a current solution implements entity beans, e.g., “Enterprise Java Bean” (EJB) that include the server-side component architecture for the J2EE platform. EJBs purportedly support rapid and simplified development of distributed, transactional, secure and portable Java applications. EJBs support a container architecture that allows concurrent consumption of messages and provide support for distributed transactions, so that database updates, message processing, and connections to enterprise systems using the J2EE architecture can participate in the same transaction context.
It would be highly desirable to eliminate the need to require programmers to learn specialized methodologies and structures such as transactions, JDBC, or entity beans that separate out component state into separate objects and to persist that state, and, instead, to automatically provide persistence and fault-tolerance for ordinary code (also called transparent fault-tolerance).
There do exist techniques for transparent fault-tolerance in distributed systems, including a technique described in U.S. Pat. No. 4,665,520 commonly owned by the assignee of the present invention. The performance of such techniques is limited by the non-determinism of the behavior of communicating components in distributed systems, as each communication from one distributed component to another needs to be logged.
Moreover, it would be highly desirable to provide an execution server that transparently supports deterministic execution, fault tolerance and high availability, to avoid the performance problems of recovering non-deterministic distributed systems.
Furthermore, it would be highly desirable to provide a simple component-based model for programmers and, particularly, to provide a system and method for making middleware functions more accessible to the application developer.